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Abstract 


To  implement  the  capabilities  conceptualized  in  Joint  Vision  2020,  complex, 
secure  networks  of  weapon  systems,  intelligence  platforms,  and  command  and  control 
mechanisms  must  be  seamlessly  integrated  and  maintained  over  time.  Accurate  and 
timely  information  will  enable  Joint  Vision  2020  key  tenets:  Dominant  Maneuver, 
Precision  Engagement,  Focused  Logistics,  and  Full  Dimensional  Protection.  These 
networks  are  central  warfighting  platforms  in  the  information  age. 

As  these  capabilities  are  developed  over  time  in  an  evolutionary  manner, 
interoperability  on  the  Net-Centric  Warfare  (NCW)  networks  is  essential,  and  both 
hardware  and  software  systems  must  be  designed  in  an  Open-systems  Architecture 
(OA)  fashion  to  accommodate  the  vast  number  of  changes  anticipated.  Professional 
Program  Management  will  be  needed  to  successfully  develop  these  key  warfighting 
platforms. 

Materiel  Developers  will  need  to  recognize  the  relatively  immature  nature  of  the 
software  engineering  domains  and  actively  compensate  for  this  immaturity.  System 
software  performance  capabilities  must  be  much  more  detailed  than  typical  hardware¬ 
centric  systems,  as  the  current  state  of  software  engineering  disciplines  is  unlikely  to 
satisfy  implied,  yet  critical  performance  requirements.  Essential  OA  performance 
characteristics  including  Maintainability,  Upgradability,  Interfaces/Interoperability, 
Reliability,  Safety  and  Security  (MUIRSS)  must  be  fully  analyzed  and  clearly 
communicated  to  the  software  developer  to  ensure  the  DoD  obtains  the  flexibility  and 
longevity  desired  from  NCW  systems. 

Keywords:  Net-Centric  Warfare,  Interoperability,  Open  Systems  Architecture,  Software 
Requirements,  System  of  Systems,  Family  of  Systems 
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Introduction 


Joint  Vision  2020  is  the  Chairman  of  the  Joint  Chiefs  of  Staff’s  guiding  document 
for  development  of  the  future  force  and  warfighting  capabilities.  It  states,  “If  our  Armed 
Forces  are  to  be  faster,  more  lethal,  and  more  precise  in  2020  than  they  are  today,  we 
must  continue  to  invest  in  and  develop  new  military  capabilities.”  It  continues,  dictating, 
“The  overall  focus  of  this  vision  is  full  spectrum  dominance — achieved  through  the 
interdependent  application  of  dominant  maneuver,  precision  engagement,  focused 
logistics,  and  full  dimensional  protection.”1  The  key  word  is  ’’interdependent,”  as  it 
prescribes  interoperability  requirements  to  a  level  never  before  achieved.  Flexible 
networks  of  complex  system-of-systems  must  be  successfully  developed  to  realize  this 
vision. 


To  implement  the  concepts  presented  in  Joint  Vision  2020,  the  Director  of  Force 
Transformation  anticipates  a  new  era: 

As  the  world  enters  a  new  millennium,  our  military  simultaneously  enters  a  new 
era  in  warfare — an  era  in  which  warfare  is  affected  by  a  changing  strategic 
environment  and  rapid  technological  change.  The  United  States  and  our 
multinational  partners  are  experiencing  a  transition  from  the  Industrial  Age  to  the 
Information  Age.  Simultaneously,  we  are  fully  engaged  in  a  global  war  on 
terrorism  set  in  a  new  period  of  globalization.  These  changes,  as  well  as  the 
experiences  gained  during  recent  and  ongoing  military  operations,  have  resulted 
in  the  current  drive  to  transform  the  force  with  network-centric  warfare  (NCW)  as 
the  centerpiece  of  this  effort.2 

This  quote  from  The  Implementation  of  Network-centric  Warfare  clearly  indicates  the 
direction  that  the  DoD  is  taking  in  developing  the  next  generation’s  warfighting 


1  Chairman  of  the  Joint  Chiefs  of  Staff  (CJCS),  Joint  Vision  2020,  June  2000.  pp  1  &  2, 


2  Director,  Force  Transformation,  Office  of  the  Secretary  of  Defense,  The  Implementation  of  Network¬ 
centric  Warfare,  5  January  2005.  p  3, 
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capabilities.  The  success  of  the  initial  NCW  systems  deployed  since  Desert  Storm,  as 
limited  as  they  were,  revealed  the  potential  battlespace  domination  offered  through 
networked  systems  providing  situational  and  information  superiority.  One  major 
challenge  in  constructing  effective  NCW  systems  is  designing  the  network  to  seamlessly 
integrate  existing,  planned  and  future  platforms  and  systems  into  a  secure,  fully 
interoperable,  near  real-time  information  system.  The  network  will  need  to 
accommodate  complex  systems  that  may  or  may  not  have  been  designed  to 
interoperate.  The  networked  systems  themselves  are  extremely  complex  and  will  have 
been  developed  decades  apart.  The  network  design  must  be  open,  flexible  and  able  to 
adapt  to  this  wide  disparity  of  system-of-systems. 

It  is  well  understood  that  an  Open-systems  Architecture  (OA)  design  is  required 
to  meet  both  current  and  future  warfighting  needs  and  is  a  critical  element  in  net-centric 
warfare  systems-of-systems  concepts.  These  highly  integrated  systems  are 
increasingly  dependent  on  software  solutions  for  integration  into  the  net-centric  scheme; 
therefore,  software  interfaces  are  one  of  the  main  keys  for  achieving  the  tactical  and 
strategic  synergies  of  the  net-centric  system.  This  paper  will  focus  on  the  challenges 
presented  when  the  Department  of  Defense  (DoD)  conducts  capabilities  analysis  and 
derives  performance  specifications  for  a  software-intensive,  net-centric,  system-of- 
systems  architecture  that  meets  OA  needs  throughout  the  life  of  the  system. 


You  got  to  be  careful  if  you  don’t  know  where  you’re  going,  because  you  might 
not  get  there!  -  Yogi  Berra 


The  DoD  Performance  Specification  development  process  transforms  the 
warfighter  requirements  into  terms  that  are  more  understandable  for  the  system 
developer,  usually  the  prime  contractor.  Typically,  the  system  performance 
requirements  are  decomposed  through  at  least  three  levels  using  the  Work  Breakdown 
Structure  (WBS)  methodology.  The  concept  is  to  provide  the  contractor  sufficient  detail 
with  regard  to  performance,  constraints,  and  intended  environments  without  stifling 
innovative  solutions  to  meeting  those  requirements.  The  number  of  WBS  levels 
developed  by  the  DoD  is  dependent  on  the  complexity  of  the  system  and  the 
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engineering  domain  maturity.  For  example,  the  automotive  engineering  discipline  is 
very  mature,  and  a  level  three  WBS  for  a  tactical  truck  system  would  most  probably  be 
sufficient.  To  determine  whether  the  WBS  is  ready  to  hand  off  to  a  contractor,  the 
Materiel  Developer  must  continue  WBS  development  to  a  point  where  either  the 
contractor  has  enough  information  to  develop  the  system  needed  by  the  warfighter,  or 
any  contractor  derived  solution  that  meets  the  stated  performance  requirements  is 
acceptable.  While  easily  stated,  this  presents  a  daunting  challenge  in  complex 
systems,  especially  those  that  are  software-intensive. 

Software  engineering  is  not  mature,  and  there  are  few  industry-wide  standards 
for  languages,  tools,  architectures,  reuse,  or  procedures.  Software  developed  for 
complex  weapon  systems  is  typically  started  from  scratch  with  each  new  system;  very 
little  existing  software  code  is  reused.  In  addition,  new  languages  and  associated  tools 
are  introduced  every  few  years.  For  this  and  other  reasons,  software  programs  grow 
exponentially  in  size  and  complexity,  expanding  desired  capabilities  but  limiting  the 
maturation  process.  The  DoD  Materiel  Developer  must  recognize  the  relative 
immaturity  of  software  engineering  when  developing  the  WBS  for  software-intensive 
systems  and,  more  importantly,  compensate  for  that  immaturity. 


The  current  state  of  software  engineering  maturity  drastically  impacts  an  area  of 
extreme  DoD  concern — Supportability.  Hardware-centric  performance  specifications 
rely  heavily  on  mature  engineering  environments  to  account  for  a  significant  portion  of 
the  system’s  supportability  performance.  Using  the  automotive  engineering  example, 
there  is  little  need  of  specifying  supportability  requirements  such  as  features  for  oil, 
filter,  tire  and  coolant  replacement  as  they  are  industry-standard  features  that  would  be 
included  in  any  competent  design.  There  are  few  corresponding  software  engineering 
standards  for  supportability  features,  and  most  commercially  based  software  is  not 
designed  for  long-term  use  as  is  typically  the  requirement  for  DoD  systems.  There  are 
literally  hundreds  of  ways  to  build  the  architecture  and  construct  the  code  for  even  the 
most  basic  software  function.  Without  physical  or  established  engineering  techniques, 
the  software  developer  is  bounded  only  by  his  or  her  imagination  and  creativity  in 
satisfying  broad  specifications.  The  resulting  software  may  function  correctly,  but  may 
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not  possess  the  OA  design  needed  to  effectively  maintain,  upgrade,  or  interface  it  with 
the  constantly  changing  net-centric  systems  and  environment. 

DoD  acquisition  professionals  must  recognize  that  the  warfighter  capabilities 
needed  require  software  development  techniques  that  differ  significantly  when 
compared  to  their  commercially  based  counterparts.  The  software  engineering 
techniques  used  in  short-lived  software  products  may  not  prove  effective  in  developing 
long-lived  DoD  software-intensive,  warfighting  systems.  DoD  systems  are  designed  to 
have  a  very  long  life  span,  including  software-intensive  systems,  in  direct  contravention 
with  most  commercially  based  software  designs.  The  need  for  OA  design — 
upgradeable,  flexible,  and  highly  reliable  software  that  is  maintainable  over  a  long  life 
span — is  paramount  to  DoD’s  warfighting  systems,  but  industry-standard  software 
engineering  techniques  do  not  necessarily  incorporate  those  features. 

What  this  means  to  the  DoD  is  that  the  capabilities  analysis  and  resulting  system 
performance  specifications  must  be  completed  in  significantly  more  detail  to  achieve 
software  performance  that  meets  warfighter’s  needs.  The  software  developer  needs  to 
be  driven  to  OA  design  by  the  performance  specifications  because  software  engineering 
discipline  and  state  of  the  practice  are  unlikely  to  provide  sufficient  architectural  designs 
without  explicit  performance  requirements  clearly  communicated.  Providing  more 
detailed  performance  specifications  seems  to  run  counter  to  acquisition  reforms 
implemented  to  allow  industry  flexibility  and  innovation  in  achieving  performance 
thresholds  and  goals,  but  that  is  not  the  intent.  The  detailed  performance  specifications 
provide  the  software  developer  much  more  information  about  areas  that  the  customer — 
DoD — sees  as  critical  to  the  overall  system  performance.  This  will  have  a  significant 
impact  on  the  system  software  design  supporting  OA  performance  and  will  provide  the 
basis  for  a  much  more  accurate  cost  and  schedule  estimate  in  the  proposal  received. 
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Near-Term  Challenges 


The  net-centric  warfare  concepts  feature  system-of-systems  in  an  elaborate 
network  requiring  a  significant  number  of  critical  interfaces.  As  each  system  is  added  or 
later  upgrades  its  capabilities,  it  likely  drives  an  interface  change  with  other  interfaced 
systems,  necessitating  the  need  for  flexibility  in  accommodating  interface  changes  from 
affected  interoperating  or  networked  systems.  It  is  easy  to  visualize  dozens  of  software 
changes  driven  by  upgrades  in  the  interfaced  components  of  the  network  and  the  critical 
need  for  effective  OA  designs  to  quickly  and  economically  accommodate  change  over  a 
long  life  span.  Again,  this  level  of  design  flexibility  is  not  a  software  industry  norm  for 
most  commercially  designed  systems. 

Safety  and  Security  requirements  for  DoD  weapon  system  software  have  few 
commercial  counterparts.  Obviously,  commercially  based  critical  medical  equipment, 
aviation  systems,  and  banking  systems  would  also  require  a  high  degree  of  safety  and 
security,  but  the  combat  environment  weapon  systems  are  intended  to  operate  within, 
and  the  military  lives  that  are  always  at  stake  adds  to  criticality  of  the  need.  The  net- 
centric  warfare  environment  will  necessarily  require  unprecedented  security  measures. 
Software  must  be  designed  to  continue  to  operate  critical  weapon  systems  in  degraded 
modes,  reject  spurious  input  without  freezing  or  failing,  and  resist  intrusion,  viruses  and 
other  attacks.  Anything  short  of  that  will  put  military  members  and  the  critical  missions 
they  perform  at  risk.  Most  commercially  based  software  engineering  disciplines  do  not 
consider  such  stringent  safety  and  security  requirements.  The  system’s  OA  design 
must  allow  for  the  flexibility  needed  while  simultaneously  ensuring  safety  and  security 
requirements.  These  two  forces  are  rarely  in  concert  and  usually  are  in  conflict. 


Considering  the  state  of  immature  software  engineering  that  exists  today,  it  is 
clear  that  DoD  will  not  achieve  the  level  of  software-intensive  system  performance 
necessary  if  the  WBS  and  performance  specification  are  not  developed  more  fully 
before  hand-off  to  the  developer  or  contractor.  Due  to  the  pressure  to  shorten  the 
acquisition  timeline,  there  is  a  tendency  to  rush  the  Request  for  Proposal  (RFP)  to  the 
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prospective  contractors  without  developing  the  WBS  below  level  three  or  including  the 
performance  specification  with  sufficient  detail.  This  approach  works  with  systems 
based  in  mature  engineering  environments  as  the  contractor  understands  that  all  of 
those  unstated  requirements  will  be  satisfied  through  the  established  engineering 
standards;  thus,  the  proposed  schedule  and  cost  estimates  will  be  fairly  accurate.  With 
a  software-intensive  system,  this  is  not  the  case  due  to  many  of  the  reasons  presented 
earlier.  The  most  diligent  contractor  can  only  provide  cost  and  schedule  estimates 
based  on  what  is  presented  in  the  RFP.  If  a  significant  portion  of  the  software 
development  effort  is  not  evident  in  the  RFP,  the  contractor  estimates  may  be  grossly 
understated,  causing  substantial — and  avoidable — funding  shortfalls  and  schedule 
overruns  that  plague  the  development  effort  throughout  the  acquisition  phase  and  well 
into  the  system’s  lifecycle. 

A  Methodology  for  Software  OA  Capabilities  Analysis 


For  DoD  software-intensive  systems  to  attain  the  broad  spectrum  of  warfighter 
performance  and  long-term  supportability  with  predictable  costs  and  schedules,  the 
Materiel  Developer  must  provide  performance  specifications  in  the  RFP  that  are 
detailed  in  areas  that  hardware-centric  systems  with  mature  engineering  environments 
need  not  be.  In  addition  to  the  system’s  software  performance  issues,  the  OA  areas  of 
Maintainability,  Upgradeability,  Interfaces/Interoperability,  Reliability,  Safety,  and 
Security  (MUIRSS)  must  be  carefully  analyzed  to  ensure  that  the  potential  contractors 
understand  the  Government  requirements  and  constraints  in  each  of  these  areas.  It  is 
likely  that  the  WBS  will  have  to  be  developed  several  more  levels  in  order  to  capture 
essential  requirements;  potential  contractors  would  need  to  see  such  WBS  development 
to  form  a  realistic  proposal  with  an  executable  schedule  and  an  accurate  cost  estimate. 


The  Systems  Engineering  Process  (SEP)  is  the  preferred  technique  for  analysis 
within  each  of  the  MUIRSS  categories  as  it  provides  a  highly  structured  and 
comprehensive  methodology  for  developing  the  WBS.  This  will  be  a  key  tool  for  the 
DoD  Materiel  Developer  in  developing  capabilities  requirements  and  communicating 
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them  to  the  software  developer  via  the  performance  specifications.  Recognizing  the 
existing  shortfalls  in  software  engineering  maturity,  this  methodology  will  greatly  assist 
the  software  developer  in  understanding  OA-related  performance  requirements;  this,  in 
turn,  will  significantly  influence  the  software  architecture  design  and  the  level  of  effort 
estimated  to  build  the  desired  system.  The  alternative  leaves  the  software  developer 
estimating  these  requirements  without  the  background  or  experience  to  do  so,  or  worse 
yet,  discovering  the  extent  of  the  actual  requirements  after  the  work  has  begun. 

The  capabilities  analysis  process  must  capture  the  OA  performance  needed  for 
supporting  the  system  throughout  its  lifecycle.  This  analysis  should  drive  a  robust  Post 
Production  Software  Support  (PPSS)  plan  addressing  the  MUIRSS  elements  of  the  OA 
design.  The  MUIRSS  elements  are  interdependent  and  tend  to  apply  across  the  system 
and  software  architecture.  Each  MUIRSS  element  is  discussed  in  the  following 
paragraphs  to  provide  a  basis  for  analyzing  capability  requirements  within  the  area  and 
capturing  performance  characteristics  that  are  essential  to  the  DoD. 

Maintainability 


The  amount  of  elapsed  time  between  initial  fielding  and  the  first  required  software 
maintenance  action  can  probably  be  measured  in  hours,  not  days.  The  effectiveness 
and  efficiency  of  these  required  maintenance  actions  is  dependent  on  several  factors, 
but  the  software  architecture  that  was  developed  from  the  performance  specifications 
provided  is  critical.  The  DoD  must  influence  the  software  architecture  through  the 
performance  specification  process  to  minimize  the  cost  and  time  required  to  perform 
essential  maintenance  tasks. 


Maintenance  is  one  area  where  software  is  fundamentally  different  from 
hardware.  Software  is  one  of  the  very  few  components  where  we  know  that  the  fielded 
product  has  shortcomings,  and  we  field  it  anyway.  There  are  a  number  of  reasons  why 
this  happens;  for  instance,  there  typically  is  not  enough  time,  funding  or  resources  to 
find  and  correct  every  error,  glitch,  or  bug,  and  not  every  one  is  worth  the  effort  of 
correcting.  Knowing  this,  there  must  be  a  sound  plan  and  resources  immediately 
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available  to  quickly  correct  those  shortcomings  that  do  surface  during  testing  and 
especially  those  that  arise  during  warfighting  operations.  Even  when  the  system 
software  is  operating  well,  changes  and  upgrades  in  other,  interfaced  hardware  and 
software  systems  will  drive  some  sort  of  software  maintenance  action  to  the  system 
software.  In  other  words,  there  will  be  a  continuous  need  for  software  maintenance  in 
the  planned  complex  system-of-systems  architecture  envisioned  for  net-centric  warfare. 

Because  the  frequency  of  required  software  maintenance  actions  is  going  to  be 
much  higher  than  in  other  systems,  the  cost  to  perform  these  tasks  is  likely  to  be  higher 
as  well.  One  of  the  reasons  for  this  is  that  software  is  not  maintained  by  ’’maintainers,” 
as  are  most  hardware  systems,  but  is  maintained  by  the  same  type  of  people  that 
originally  developed  it — software  engineers.  These  engineers  will  be  needed 
immediately  upon  fielding,  and  a  number  will  be  needed  throughout  the  lifespan  of  the 
system  to  perform  maintenance,  add  capabilities,  and  upgrade  the  system.  There  are 
several  models  available  to  estimate  the  number  of  software  engineers  that  will  be 
needed  for  support;  planning  for  funding  these  resources  must  begin  very  early  in  the 
process.  As  the  DoD  has  a  very  limited  capability  for  supporting  software  internally, 
typically,  early  software  support  is  provided  by  the  original  developer  and  is  included  in 
the  RFP  and  proposal  for  inclusion  into  the  contract  or  as  a  follow-on  Contractor 
Logistics  Support  (CLS)  contract. 

Upgradeability 


A  net-centric  environment  composed  of  numerous  systems  developed  in  an 
evolutionary  acquisition  model  will  create  an  environment  of  almost  continuous  change 
as  each  system  upgrades  its  capabilities  over  time.  System  software  will  have  to 
accommodate  the  changes  and  will  have  to,  in  turn,  be  upgraded  to  leverage  the 
consistently  added  capabilities.  The  software  architecture  design  will  play  a  major  role 
in  how  effective  and  efficient  capabilities  upgrades  are  implemented,  so  communicating 
the  known,  anticipated  and  likely  system  upgrades  will  impact  how  the  software 
developer  designs  the  software  for  known  and  unknown  upgrades. 
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Trying  to  anticipate  upgrade  requirements  for  long-lived  systems  is  extremely 
challenging  to  Materiel  Developers,  but  is  well  worth  their  effort.  Unanticipated  software 
changes  in  the  operational  support  phase  cost  50  to  200  times  the  cost  in  early  design; 
so,  any  software  designed  to  accommodate  an  upgrade  that  is  never  realized  costs 
virtually  nothing  when  compared  to  changing  software  later  for  a  capability  that  could 
have  been  anticipated.  For  example,  the  Army  Tactical  Missile  System  (ATACMS) 
Unitary  was  a  requirement  to  modify  the  missile  from  warhead  air  delivery  to  surface 
detonation — that  is,  flying  the  warhead  to  the  ground.  The  contract  award  was  for  $119 
million  for  the  modification.  The  warhead  was  not  new  technology,  nor  particularly 
challenging  to  integrate  with  the  missile  body.  The  vast  majority  of  this  cost  was  to 
reengineer  the  software  to  guide  the  missile  to  the  surface.  Had  there  been  an  upgrade 
requirement  for  this  type  of  mission  in  the  original  performance  specification,  this 
original  cost  (including  potential  upgrades,  even  if  there  were  ten  other  upgrade 
requirements  that  were  never  applied)  would  have  been  a  fraction  of  this  modification 
cost. 

Interfaces/Interoperability 


OA  design  focuses  on  the  strict  control  of  interfaces  to  ensure  the  maximum 
flexibility  in  adding  or  changing  system  modules,  whether  they  are  hardware  or  software 
in  nature.  This  presupposes  that  the  system  modules  are  known — which  seems  logical, 
as  most  hardware  modules  are  well  defined  and  bounded  by  both  physics  and  mature 
engineering  standards.  In  sharp  contrast  to  hardware,  software  modularity  is  not 
bounded  by  physics,  and  there  are  very  few  software  industry  standards  for  the  modular 
architecture  in  software  components.  This  is  yet  another  area  where  the  software 
developer  needs  much  more  information  about  operational,  maintenance,  reliability, 
safety  and  security  performance  requirements,  as  well  as  current,  planned  and  potential 
system  upgrades.  These  requirements,  once  well-defined  and  clearly  communicated, 
will  drive  the  developer  to  design  a  software  modular  architecture  supporting  OA 
performance  goals.  For  example,  if  a  system  uses  a  Global  Positioning  System  (GPS) 
signal,  it  is  likely  that  the  GPS  will  change  over  the  life  of  the  system.  Knowing  this,  the 
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software  developer  creates  a  corresponding  discrete  software  module  that  is  much 
easier  and  less  expensive  to  interface,  change  and  upgrade  as  the  GPS  system  does 
so. 


With  the  system  software  modular  architecture  developed,  the  focus  returns  to 
the  interfaces  between  hardware  and  software  modules,  as  well  as  the  external 
interfaces  needed  for  the  desired  interoperability  of  the  net-centric  force.  Software  is,  of 
course,  one  of  the  essential  enablers  for  interoperability  and  provides  a  powerful  tool  for 
interfacing  systems,  including  systems  that  were  not  designed  to  work  together. 

Software  performing  the  function  of  ’’middleware”  allows  legacy  and  other  dissimilar 
systems  to  interoperate.  Obviously,  this  interoperation  provides  a  significant  advantage, 
but  comes  with  a  cost  in  the  form  of  maintainability,  resources  and  system  complexity. 
As  software  interfaces  with  other  components  and  actually  performs  the  interface 
function,  controlling  it  and  ensuring  the  interfaces  provide  the  desired  OA  capability 
becomes  a  major  software-management  and  software-discipline  challenge. 

One  method  being  employed  by  the  DoD  attempts  to  control  the  critical 
interfaces  through  a  set  of  parameters  or  protocols  rather  than  active  management  of 
the  network  and  network  environment.  This  method  falls  short  on  several  levels.  It  fails 
to  understand  and  control  the  effects  of  aggregating  all  of  the  systems  in  a  net-centric 
scheme.  For  instance,  each  individual  system  may  meet  all  protocols  for  bandwidth,  but 
when  all  systems  are  engaged  on  the  network,  all  bandwidth  requirements  are 
aggregated  on  the  network — overloading  the  total  bandwidth  available  for  all  systems. 

In  addition,  members  of  the  Software  Engineering  Institute  (SEI)  noted: 


While  these  standards  may  present  a  step  in  the  right  direction,  they  are  limited 
in  the  extent  to  which  they  facilitate  interoperability.  At  best,  they  define  a 
minimal  infrastructure  that  consists  of  products  and  other  standards  on  which 
systems  can  be  based.  They  do  not  define  the  common  message  semantics, 
operational  protocols,  and  system  execution  scenarios  that  are  needed  for 
interoperation.  They  should  not  be  considered  system  architectures.  For 
example,  the  C4ISR  domain-specific  information  (within  the  JTA)  identifies 
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acceptable  standards  for  fiber  channels  and  radio  transmission  interfaces,  but 
does  not  specify  the  common  semantics  of  messages  to  be  communicated 
between  C4ISR  systems,  nor  does  it  define  an  architecture  for  a  specific  C4ISR 
system  or  set  of  systems.3 

Clearly,  understanding  and  controlling  the  interfaces  is  critical  for  effective 
interoperation  at  both  the  system  and  system-of-systems  level.  The  individual  program 
manager  must  actively  manage  all  systems’  interfaces  impacting  OA  performance,  and 
a  network  PM  must  do  the  same  for  the  critical  network  interfaces.  Due  to  this 
necessity  of  constant  management,  a  parameters  and  protocols  approach  to  net-centric 
OA  performance  is  unlikely  to  produce  the  capabilities  and  functionality  expected  by  the 
warfighter. 

Understanding  the  software  interfaces  begins  with  the  software  architecture; 
controlling  the  interfaces  is  a  unique  challenge  encompassing  the  need  to  integrate 
legacy  and  dissimilar  systems  and  the  lack  of  software  interface  standards  within  the 
existing  software  engineering  environment.  As  stated  earlier,  the  architecture  needs  to 
be  driven  through  detailed  performance  specifications,  which  will  help  define  the 
interfaces  to  be  controlled.  An  effective  method  for  controlling  the  interfaces  is  to 
intensely  manage  a  well-defined  Interface  Control  Document  (ICD),  which  should  be  a 
Contract  Data  Requirements  List  (CDRL)  deliverable  on  any  software-intensive  or 
networked  system. 

Reliability 

While  the  need  for  highly  reliable  weapon  systems  is  obvious,  the  impact  on  total 
system  reliability  of  integrating  complex  software  components  is  not  so  obvious. 
Typically,  as  system  complexity  increases,  maintaining  system  reliability  becomes  more 
of  a  challenge.  Add  the  complexity  of  effectively  networking  a  system-of-systems  (all  of 


3  Edwin  Morris,  Linda  Levine,  Craig  Meyers,  Pat  Place,  and  Dan  Plakosh,  System  of  Systems 
Interoperability  (SOSI):  Final  Report,  Carnegie  Mellon  Software  Engineering  Institute,  April  2004.  p  38, 
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which  are  individually  complex)  to  a  critical  warfighting  capability  that  is  constantly 
evolving  overtime,  and  reliability  becomes  daunting. 

Once  again,  the  software  developer  must  have  an  understanding  of  reliability 
requirements  before  crafting  the  software  architecture  and  developing  the  software 
applications.  Highly  reliable  systems  often  require  redundant  capability,  and  this  holds 
true  for  software  components  as  well.  In  addition,  software  problems  tend  to  propagate, 
resulting  in  a  degradation  of  system  reliability  over  time.  For  example,  a  Malaysian 
Airlines  Boeing  777  suffered  several  flight  control  problems  resulting  in:  a  near  stall 
situation,  contradicting  instrument  indications,  false  warnings,  and  difficulty  controlling 
the  aircraft  in  both  autopilot  and  manual  flight  modes.  The  problem  was  traced  to 
software  in  an  air  data  inertial  reference  unit  that  was  feeding  erroneous  data  to  the 
aircraft’s  primary  flight  computer  (PFC),  which  is  used  in  both  autopilot  and  manual  flight 
modes.  The  PFC  continued  to  try  to  correct  for  the  erroneous  data  received,  adjusting 
flight  control  surfaces  in  all  modes  of  flight,  displaying  indications  that  the  aircraft  was 
approaching  stall  speed  and  overspeed  limits  simultaneously,  and  causing  wind  shear 
alarms  to  sound  close  to  landing.4  It  is  critical  for  system  reliability  that  the  software 
developers  understand  how  outputs  from  software  applications  are  used  by  interfaced 
systems  so  that  appropriate  reliability  safeguards  can  be  engineered  into  the  developed 
software. 

Software  that  freezes  or  shuts  down  the  system  when  an  anomaly  occurs  is 
certainly  not  reliable  nor  acceptable  for  critical  weapon  systems;  yet,  these 
characteristics  are  prevalent  in  commercially  based  software  systems.  Mission 
reliability  is  a  function  of  the  aggregation  of  the  system’s  subcomponent  reliability,  so 
every  software  subcomponent  is  contributing  to  or  detracting  from  that  reliability.  The 
complexity  of  software  makes  understanding  all  failure  modes  nearly  impossible,  but 
there  are  many  techniques  that  software  developers  can  employ  when  designing  the 
architecture  and  engineering  the  applications  to  improve  the  software  component 


4  Michael  A.  Dornheim,  “A  Wild  Ride,”  Aviation  Week  &  Space  Technology  Volume  163  (September 
2005).  p  46. 
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reliability.  Once  requirements  are  clearly  communicated  to  the  developers,  the  software 
can  be  engineered  with  redundancy  or  ’’safe  mode”  capabilities  to  vastly  improve 
mission  reliability  when  anomalies  occur.  The  key  is  identifying  the  reliability 
requirements  and  making  them  clear  to  the  software  developers. 

Safety 

Very  few  software  applications  have  the  required  safety  margins  associated  with 
critical  weapon  systems  used  by  warfighters  in  combat  situations — where  they  are 
depending  on  these  margins  for  their  survival.  Typically,  the  software  developers  have 
only  a  vague  idea  of  what  their  software  is  doing  and  how  critical  that  function  is  to  the 
warfighter  employing  the  weapon  system.  Safety  performance  must  be  communicated 
to  the  software  developers  from  the  beginning  of  development  so  they  have  the  link 
between  software  functionality  and  systems  safety.  For  example,  suppose  a  smart 
munition  senses  that  it  does  not  have  control  of  a  critical  directional  component,  and  it 
calculates  that  it  cannot  hit  the  intended  target.  The  next  set  of  instructions  the  software 
provides  to  the  malfunctioning  system  may  well  be  critical  to  the  safety  of  friendly 
troops,  so  software  developers  must  have  the  necessary  understanding  of  operational 
safety  to  decide  how  to  code  the  software  for  what  will  happen  next. 

Software  safety  is  clearly  linked  with  reliability,  as  software  that  is  more  reliable  is 
inherently  safer.  It  is  critical  that  the  software  developer  understands  how  the  warfighter 
expects  the  software  to  operate  in  abnormal  situations,  degraded  modes,  and  when 
inputs  are  outside  of  expected  values.  Much  commercially  based  software  simply 
ceases  to  function  under  these  conditions  or  gives  error  messages  that  supercede 
whatever  function  was  being  performed,  none  of  which  are  acceptable  in  combat 
operations. 

Security 


With  software  performing  so  many  critical  functions,  there  is  little  doubt  that 


software  applications  are  a  prime  target  for  anyone  opposing  US  and  Allied  forces. 
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Critical  weapon  system  and  networking  software  must  be  resistant  to  hacking,  spoofing, 
mimicking,  and  all  other  manner  of  attack.  There  must  be  capabilities  of  isolating 
attacks  and  portions  of  networks  that  have  been  compromised  without  losing  the  ability 
to  continue  operations  in  critical  combat  situations.  The  software  developer  must  know 
all  these  capabilities  are  essential  before  he/she  constructs  software  architectures  and 
software  programs,  as  this  knowledge  will  be  very  influential  for  the  software  design  and 
application  development. 

Interoperability  challenges  are  increased  when  the  system-of-systems  have  the 
type  of  security  requirements  needed  by  the  DoD.  Legacy  systems  and  existing 
security  protocols  will  likely  need  to  be  considered  before  other  security  architecture  can 
be  effectively  designed.  OA  capabilities  will  be  hampered  by  the  critical  need  for 
security;  both  must  be  carefully  balanced  to  optimize  system  performance  and  security. 
This  balance  of  OA  and  security  must  be  managed  by  the  DoD  and  not  the  software 
developer. 

Physical  security  schemes  and  operating  procedures  will  also  have  an  impact  on 
the  software  architecture.  For  example,  many  communication  security  (COMSEC) 
devices  need  only  routine  security  until  the  keys,  usually  software  programs,  are 
applied;  then,  much  more  stringent  security  procedures  are  implemented.  Knowledge 
of  this  security  feature  would  be  a  key  requirement  of  the  developer;  he/she  must 
understand  how  and  when  the  critical  software  pieces  are  uploaded  to  the  COMSEC 
device.  The  same  holds  true  for  weapon  systems  that  upload  sensitive  mission  data 
just  prior  to  launch. 


Residual  software  on  equipment  or  munitions  that  could  fall  into  enemy  hands 
presents  another  type  of  security  challenge  that  needs  to  be  addressed  during  the 
application  development.  For  example,  the  ATACMS  missile  air-delivers  some  of  its 
warheads,  leaving  the  missile  body  to  freefall  to  the  surface.  It  is  very  conceivable  that 
the  body  could  be  intact  and,  of  course,  unsecured.  If  critical  mission  software  was  still 
within  the  body  and  found  by  enemy  forces,  valuable  information  may  be  gleaned  from 
knowing  how  the  system  finds  its  targets.  We  would  certainly  want  the  developer  to 
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design  the  applications  in  a  way  that  would  make  anything  recovered  useless  to  the 
enemy,  but  this  is  a  capability  that  is  not  intuitive  to  the  software  developers. 

Network  Development 

The  network  is  a  lynchpin  for  the  combat  effectiveness  of  NCW  architecture,  and 
as  such,  should  be  developed  under  a  professional  Program  Management  (PM) 
organization.  The  US  Navy  has  achieved  optimal  results  by  assigning  a  PM  for  the  Link 
16  Program  as  noted  by  SEI:  “The  Navy  created  a  PMO  and  funded  it  with  money  from 
affected  programs.  These  monies  were  returned  to  programs  specifically  to  work 
toward  Link  16  capability.”5  SEI  goes  on  to  describe  the  need  for  professional  program 
management  by  stating,  “What  is  needed  are  processes  that  help  to  reach  agreements, 
blinders  that  avoid  getting  distracted  by  things  that  are  not  related  (e.g.,  portability),  and 
to  be  agnostic  about  specific  technologies  (e.g.,  CORBA  or  Message  Oriented 
Middleware).”6  A  network  PM  would  help  facilitate  and  broker  those  agreements  to  the 
benefit  of  the  network,  vastly  increasing  the  probability  that  the  NCW  asset  will  provide 
the  warfighter  the  capability  and  advantage  visualized  by  DoD. 


5  Edwin  Morris,  Linda  Levine,  Craig  Meyers,  Pat  Place,  and  Dan  Plakosh,  System  of  Systems 
Interoperability  (SOSI):  Final  Report  (Carnegie  Mellon  Software  Engineering  Institute,  April  2004):  p  33. 
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Summary 


To  get  the  needed  Open  Architecture  performance  the  DoD  is  seeking  for 
software  components,  the  Material  developer  will  have  to  specify  it  in  the  RFP  and 
Performance  Specification.  Unlike  many  hardware-centric  engineering  environments, 
the  immature  software  engineering  environment  is  unlikely  to  compensate  for  essential 
performance  that  is  not  specified.  With  the  Materiel  Developer  performing  the 
capabilities  analysis  using  the  MUIRSS  approach  outlined  above,  the  potential  software 
developers  will  be  provided  a  much  more  detailed  understanding  of  critical  capabilities 
the  DoD  expects  from  its  software  components. 

This  same  technique  should  result  in  significantly  more  accurate  proposals  as 
much  more  of  the  software  development  work  can  be  estimated  from  the  RFP  and 
Performance  Specification  provided.  Yes,  proposals  will  likely  continue  to  be  overly 
optimistic,  especially  in  a  competitive  environment.  And  yes,  changes  and  details  will 
still  be  revealed  after  the  contract  is  signed — but  the  cost  growth  should  be  in  the  range 
of  ten  percent  of  the  cost,  not  the  current  average  of  one-hundred  percent  of  the  original 
proposal.  Schedule  estimates  will  also  be  much  more  accurate  as  the  scope  of  the 
software  work  is  better  understood  by  the  contractors,  keeping  schedule  slippage  to 
under  fifteen  percent  of  the  original  proposal  estimate. 

Conducting  this  analysis  will  be  as  challenging  as  it  is  time-consuming,  especially 
since  it  is  applied  in  the  early  stages  of  the  acquisition  process  when  there  is  great 
pressure  to  “get  the  RFP  on  the  street.”  The  enormous  potential  time  and  cost  savings 
realized  throughout  the  remaining  development  and  the  system’s  lifecycle  by  completing 
the  thorough  MUIRSS  capability  analysis  warrants  the  needed  analysis  time.  There  is 
an  old  carpenter’s  adage  that  applies  well  in  this  case:  “measure  twice,  cut  once.” 
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